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Overview 

Kernel Patch Guard runs every ~3-5 minutes and causes an exception if kernel signature fails (i.e. if kernel is patched). 
Leading theory is the patch guard is implemented in Trust Zone (Secure World) ELI . 

The patch guard seems to only protect the physical pages that the kernel resides in (0x800C00000 - ?), but not the page 
tables themselves. The kernel can be "patched" by creating a new page, copying the old page in, patching it, and then 
mapping the modified page into kernel memory. 

Background 

• TrustZone 

• User code runs in Normal World ELO 

• iOS Kernel runs in Normal World ELI 

• EL3, or Secure Monitor, is (and should only be) used for switching between Secure & Normal 
World. We have not yet been able to dump the Monitor code from any device :( So can't be 
sure of this, but from all the code we have looked at, this is our best guess. 

• EL3 spans Secure & Normal, it is the king of the hill 

• Patch Guard runs in Secure World ELI (best guess). 


Research 

• iBoot-iPhone7,2_12B440 

• Does NOT contain the patch guard but was the only iBoot laying around at the time to take a 
look at. 

• Boots into Secure World. When the processor boots it starts in Secure World (EL3?) 

• Synchronous _lower_el_64 exception vector is at Address 0x0001 F404 (relative to 0x0). 

• This code checks to make sure that ESR_EL3 is equal to 0x5E005EC3 which parses out to 
be: 

• SMC instruction execution in AArch64 state, when SMC is not disabled 

• 32-bit instruction trapped 

• 0x5EC3 = The value of the immediate field from the issued SMC instruction 

• Then it branches to the address in xO. At this time, the processor is in the EL3 state, which is 
the highest trusted security state (can do anything, like read/write to secure memory and 
secure EL3 registers). Presumably, the function that is called is responsible for cleaning up 
and performing an eret (Exception Return) back to normal execution, after its finished doing 
whatever it needs/wants to do. 

• Seems like you can put any PHYSICAL address of a function (in in-secure memory) 
into xO and do a smc 0x5EC3 instruction (from kernel - ELI) and that function will be 
executed in the context of Secure Monitor Mode (EL3). 

• However, the iBoot smc handler might not be the correct one at runtime, since 
iBoot seems loads another monitor (with IMG4 tag 'hypr') that may have a 
different smc handler (i.e. smc 0x1 1 - see below) 

• Kernel-iPhone7,2_9.0_13A4293g 

• This firmware DOES have the patch guard. We don't have an iBoot dump for this (yet), but 
we looked at the kernel side of things. 

• Only smc instruction in kernel is at 0xFFFFFF801 C303460. It is an smc 0x1 1 . 

• Seems like this new interface requires 4 parameters: 

• xO: 0x800 

• xl : Physical address to a function 

• x2: 0 

• x3: 0 

• Our best guess, by looking at the function that is passed into xl , is that this code is run in 
Secure Mode ELI (Secure Kernel?). This code is responsible for context swtiching into and 
out of secure world. This function resides in in-secure world inside the regular kernel (crazy). 

• This would mean the Secure Monitor (running in EL3) is responsible for context switching to 
Secure ELI and executing this function. 

• This smc interface (smc 0x11) is different than the v8.x interface (smc 0x5EC3). Apple 
obviously has changed this. Tried calling smc 0x5EC3 on a iPhone6 9.0 Beta and caused an 
exception (similar to the exception Tom received during his testing - conclusion is its a bad 
smc call). Used Mike's kext capability to do this. 
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